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Abstract 

A toolset for the rapid development of small satellite systems 
has been created. The objective of this tool is to support the 
definition of spacecraft mission concepts to satisfy a given set 
of mission and instrument requirements. The toolset will 
perform the following functions: 

• Using instrument performance and mission requirements 
as input, a design and sizing module will define a concept 
for a satellite configuration, including all subsystems, 
which will satisfy those requirements. Each subsystem 
will be defined to component levels consisting of 
estimated technical characteristics and resource 
requirements. Actual components may then be identified 
using a component level database or design output may 
go directly to the simulation module for analysis. This 
module is developed in Microsoft Excel, thus enhancing 
portability of the module. 

• Given the design/sizing data generated, a simulation 
module will analyze the operational system by simulating 
resource interaction as a function of time. This will be 
accomplished by creating a virtual spacecraft 
environment in which to operate the spacecraft. This tool 
will identify operational interaction conflicts among 
subsystems. The simulation module also has the 
capability to simulate failure modes. The simulation 
module is developed using object-oriented system 
modeling tool, MATLAB Simulink. 

• Using the satellite definition, a costing model will 
determine Rough Order of Magnitude (ROM) subsystem 
costs based on component level costs and will allow 
comparison of relative costs of different designs and 
different technologies. 


The primary function of the Spacecraft Systems Design & 
Simulation Environment (SSDSE) is to assist in designing, 
sizing, simulating, and costing satellite systems based on 
mission/payload requirements and current/advanced satellite 
systems data. There are four core modules to SSDSE, as 
shown in Figure 1. The System Design and Sizing Module is 
where the concept definition begins. Given a set of 
mission/payload requirements and constraints the System 
Design and Sizing Module synthesizes subsystem 
characteristics. The System Resource Simulation Module 
utilizes the newly generated subsystem characteristics 
parameters to perform an integrated timed simulation of the 
spacecraft systems to identify resource bottlenecks or 
inadequacies resulting from simple assumptions in the System 
Design and Sizing Module. Adjustments are then made in the 
subsystem characteristics to eliminate the problems identified 
in the simulation. The Component Level Database can then be 
used to identify actual candidate system components based on 
the subsystem characteristics definition or to flag areas where 
there may be technology tall poles or where components with 
the required characteristics do not exist or for which the data is 
not available. The Component Level Database could, 
alternately, be used as a starting template for the design 
process based on historical mission/system data. Once a 
detailed satellite description has been generated, the Costing 
Module is then utilized to determine funding requirements for 
the concept. Adjustments in mission requirements and 
technology assumptions can then be changed and the cycle 
repeated. Once a spacecraft concept has been 


designed/sized and then evaluated with the system simulation 
module, a cost analysis will be required. Cost analysis output 
should include development, manufacturing, and operational 
phases of the spacecraft. The basis of the cost estimating 
should be derived directly from the output of the design/sizing 
module and/or the component level database. The ability to 
assess the effect of different bus or sensor technologies, 
changes in procurement and launch schedules as well as 
operational strategies should be included in the costing 
capabilities. 

The objective of this report is to provide an introduction to 
understanding and using the SMALLSAT Model. SMALLSAT is 
a computer-aided Phase A design and technology evaluation tool 
for small satellites. SMALLSAT enables satellite designers, 
mission planners, and technology program managers to observe 
the likely consequences of their decisions in terms of satellite 
configuration, non-recurring and recurring cost, and mission life 
cycle costs and availability statistics. It was developed by 
Princeton Synergetics, Inc. and User Systems, Inc. as a revision 
of the previous TECHSAT Phase A design tool, which modeled 
medium-sized Earth observation satellites. Both TECHSAT and 
SMALLSAT were developed for NASA. 

SMALLSAT: The Design and Sizing tool. In SMALLSAT, a 
satellite is configured in terms of sensor attributes, such as 
dynamic mass, dimensions, data and power profiles, and 
pointing and stabilization requirements, and bus subsystem 
technology. SMALLSAT models the satellite in terms of nine 
subsystems: attitude reference and control, power, thermal, 
orbital maintenance, propulsion, data handling, on-board 
computer, TT&C, and structure. The design of these 
subsystems is iterated so as to take into account their mass and 
power interactions. 

SMALLSAT contains sensor, launch vehicle, and bus subsystem 
technology databases. The user can select input from these 
databases during satellite configuration. The user can also 
selectively override this input to model new technology 
developments. This enables analysis of technology impacts on 
satellite configuration and costing. For example, launch vehicles 
can either be selected from the database, in which case they 
place constraints on satellite configuration, or they can be 
selected based upon the resulting satellite configuration. 
Modifying launch vehicle attributes allows the effect of new 
launch capability to be ascertained in terms of satellite 
configuration and cost, and mission life cycle cost. In addition, 
bus subsystem technology levels, such as solar cell efficiency, 
can be selectively altered to reflect likely technology advances or 
the technology advance that is sought through a specific 
technology program. This will allow the likely effects of 
technology programs to be observed in terms of satellite 
configuration, cost, and the ability to switch launch vehicles. 

The impact of the resulting satellite configuration on mission life 
cycle cost and sensor availability statistics may also be 
determined using SMALLSAT. A set of cost estimating 
relationships (specifically developed for small satellites by the 
Aerospace Corp.) contained within SMALLSAT is utilized to 
provide estimates of both non-recurring and unit recurring costs 
at the subsystem level. The estimated costs may be selectively 
overridden by specifying expected values or standard deviation, 
or both. This allows the uncertainty of costing associated with 
the introduction of new technology to be explicitly and 
quantitatively considered. An integrated Monte Carlo simulation 
model determines the resulting life cycle cost and availability 
statistics based on user-specified mission parameters such as 
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number of satellites required, their desired launch dates, satellite 
sparing and replacement strategies, and cost spreading 
functions. 

The SMALLSAT Model is an integration of Microsoft Excel and 
FORTRAN (compiled code) software operating within the 
Microsoft Windows environment on personal computers. For 
satellite designers, SMALLSAT can be used to provide 
preliminary configuration and cost estimates and can provide 
information for launch vehicle selection. It can provide a rapid 
and flexible approach for assessing the implication of different 
combinations of sensors on satellite configuration and cost. 

For technology program planners, SMALLSAT provides the 
ability to assess the potential impacts of investments in sensor 
and spacecraft bus technology development programs. The 
impacts of the technology programs can be measured in terms of 
resulting spacecraft configuration and cost changes, changes in 
launch vehicle requirements (for example, the ability to utilize a 
smaller launch vehicle), and changes in mission life cycle cost 
and sensor availability statistics. 

For mission planners, SMALLSAT provides the ability to rapidly 
configure Earth observation satellites and missions utilizing 
satellites with different combinations of sensors. SMALLSAT 
can provide estimates of satellite configuration and cost and 
mission life cycle cost and sensor availability statistics 

The SMALLSAT Model. SMALLSAT is a computer-aided 
Phase A design and technology evaluation tool for small 
satellites. "Small" refers to satellites ranging from those in the 
200 kg class, to those that can be manifested on vehicles less 
than the capability of a Delta. SMALLSAT enables satellite 
designers, mission planners, and technology program managers 
to observe the likely consequences of their decisions in terms of 
satellite configuration, non-recurring and recurring cost, and 
mission life cycle costs and availability statistics. 

SMALLSAT employs a pull-down menu structure to lead the user 
through the system. The starting point is specification of mission 
parameters beginning with the launch vehicle destination 
(parking orbit, inclination and altitude) and the final location and 
lifetime that the satellite subsystems are to achieve The next 
step is the specification of the payload which is accomplished by 
selecting (and modifying as deemed to be necessary) a mix of 
sensors from the payload (sensor) database. Up to five sensors 
may be selected having attributes such as electronics mass, 
aperture mass and dynamics, physical dimensions, pointing 
accuracy, data and power operating profiles, as well as other 
attributes. These attributes may be used as provided or altered 
to reflect a new sensor configuration. The satellite is then 
configured in terms of these sensor attributes which impose a set 
of requirements upon the satellite bus. In other words, the bus is 
configured to fly the identified sensors. 

SMALLSAT models the satellite in terms of eight subsystems: 
attitude reference and control, power, thermal, orbital 
maintenance & propulsion, command & data handling, TT&C, 
and structure. Each of these subsystems is characterized as a 
set of design equations. A combination of sensor requirements, 
user-input data provided in response to computer generated 
queries and user overrides of database data and results of model 
calculations, and database data serve as the source of 
information used in the design equations. 

SMALLSAT contains sensor, satellite, launch vehicle, and 
subsystem technology databases. The user can select input 


from these databases during satellite configuration. The user 
can also selectively override this input to model new technology 
developments. This enables analysis of technology impacts on 
satellite configuration and costing. Modifying launch vehicle 
attributes allows the effect of new launch capability to be 
ascertained in terms of satellite configuration and cost, and 
mission life cycle cost. In addition, subsystem technology levels, 
such as solar cell efficiency, can be selectively altered to reflect 
likely technology advances or the technology advance that is 
sought through a specific technology program. This will allow the 
likely effects of technology programs to be observed in terms of 
satellite configuration, cost, and the ability to switch launch 
vehicles. 

The impact of the resulting satellite configuration on mission life 
cycle cost and sensor availability statistics may also be 
determined using SMALLSAT. A set of cost estimating 
relationships (specifically developed for small satellites by the 
Aerospace Corp.) contained within SMALLSAT is utilized to 
provide estimates of both non-recurring and unit recurring costs 
at the subsystem level. SMALLSAT calculates the variables that 
are used in the cost estimating relationships (CERs). The 
estimated costs may be selectively overridden by specifying 
expected values or standard deviation, or both. This allows the 
uncertainty of costing associated with the introduction of new 
technology to be explicitly and quantitatively considered. The 
approach for considering uncertainty is described in detail in 
Appendix G. 

An integrated Monte Carlo simulation model, SATCAV,’ 
determines the resulting life cycle cost and availability statistics 
based on user-specified mission parameters such as number of 
satellites required, their desired launch dates, satellite sparing 
and replacement strategies, and cost spreading functions. 

Satellite non-recurring and recurring cost data and launch vehicle 
cost data are provided over a seamless interface to the life cycle 
costing model that develops annual cost and present value of life 
cycle cost statistics, annual event statistics, sensor availability 
statistics and other related information. 

SMALLSAT contains a number of databases. These include 
databases that relate to sensors (i.e., payloads), satellites, 
power, atmospheric density, fuel, attitude reference and control, 
and launch vehicle performance. The sensor database contains 
information on over 100 sensors. Up to five of these may be 
selected to form the specific payload for the small satellite that is 
being designed. As these sensors are selected, the values of 
the associated sensor attributes (i.e., power, data rate, 
dimensions, etc.) are input into the input stream. Each of the 
attributes may be over-ridden (i.e,, changed) to reflect sensor 
design changes or to simulate technology changes. Almost 
everywhere in the model, input and output values can and may 
be overridden. This is an essential feature of the model. The 
ability to override values enables the engineers and scientists to 


SMALLSAT includes Princeton Synergetics, Inc. (PSI) 
proprietary software, denoted as SATCAV, that is 
used for performing life cycle cost and sensor 
availability analyses. SATCAV is not to be copied 
without express written authorization from Princeton 
Synergetics, Inc. SMALLSAT is configured so that 
the satellite design and costing functions can be 
performed without having SATCAV. SATCAV (in the 
form of compiled FORTRAN code) is commercially 
available and can be obtained from PSI with 
instructions for its installation into SMALLSAT. 
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be innovative as well as customize the system to further satisfy 
their requirements 


Spacecraft Subsystem Models The SMALLSAT Model 
contains eight integrated subsystem design models (Propulsion 
& Orbit maintenance, Attitude Reference & Control, Power, 
Thermal, Data Handling, On-Board Computer, TT&C, and 
Structure) and associated databases (see above). The mission 
specification, in the form of launch vehicle destination and 
satellite life, and payload specification, in the form of data and 
power operating profiles, dynamic mass, pointing accuracy, 
stability, etc., place requirements upon the various subsystems 
that comprise the satellite that is to be configured with 
SMALLSAT. 

The Attitude Reference and Control System (ARC) model 
establishes the stabilization methods that may be appropriate 
based upon mission and payload inputs. The selected 
stabilization method identifies the number of reaction wheels, 
momentum wheels, magnetic torquers, IRUs, sun sensors, star 
sensors, Earth sensors and magnetometers that are required. 

As in most instances, the model developed results may be over- 
ridden by user inputs. The final result is the determination of the 
ARC actuators and sensors and attitude sensor mass, attitude 
control mass, and overall subsystem mass. 

The Power subsystem supplies electrical power to the satellite, 
then store, regulates and distributes the power. SMALLSAT 
calculates the subsystem mass by taking the satellites end-of-life 
(EOL) power and works backward to determine the satellites 
beginning-of-life (BOL) power requirements. When the BOL 
power is known, SMALLSAT sizes the solar array, batteries and 
power distribution system. Solar cell BOL watts/area and 
watts/mass are selected from tables which lists average values 
for solar cell types. These values may be over-ridden when 
desired. Solar array sizing takes into account sun incidence 
angle, battery type, eclipse cycle, power duty cycle, stabilization 
method, and other related factors. The final result is the 
determination of BOL and EOL power and power subsystem 
mass. 

The spacecraft thermal subsystem is used to heat and cool the 
spacecraft and payload components. A combination of active 
and passive methods may be used to achieve thermal 
requirements. The Thermal subsystem mass is calculated as a 
percentage of spacecraft dry mass and is based upon historic 
satellite data. Special thermal systems such as cryogenic 
coolers are not accounted for and should be added as payload if 
required. 

The satellite propulsion subsystem is used to take the spacecraft 
from a parking orbit to a final orbit. The spacecraft design may 
integrate the propulsion subsystem with the orbital maintenance 
subsystem or may choose a "stand-alone” stage for the perigee 
kick from a transfer orbit. The propulsion subsystem calculates 
the fuel mass (based upon a selection of fuel type and 
associated specific impulse) required to transfer from an initial 
parking orbit to the final satellite orbit and propellant tank and 
thruster mass. 

The Orbital Maintenance subsystem calculates the amount of 
propellant needed to keep the satellite in the desired orbit. 
Propellant mass takes into account the specific impulse of the 
propellant (selected from a database or over-ridden). 

Atmospheric density (a function of solar state and satellite 
altitude) is taken into account as is the satellite ballistic 


coefficient. For GEO missions, North/South and East/West 
stationkeeping requirements are considered and are the result of 
Sun and Moon gravitational effects as well as non-uniformity of 
the Earth's gravitational field. 

The Data Handling subsystem collects data from the sensors 
and sends the data to the ground. The collected data may be 
transmitted as it is collected or recorded for later transmission. 
Data transmission may be either direct to a ground station and/or 
to a ground station via a communication satellite, such as 
TDRSS. Based upon a selected downlink method and 
frequencies and the use of on-board recorders, SMALLSAT 
calculates the downlink rate (Kbps) and establishes downlink 
options from which the user may select. SMALLSAT then 
calculates the subsystem weight and power requirements using 
a database of historic transponder, antenna and recorder 
weights. 

The Tracking, Telemetry and Control (TT&C) subsystem usually 
has a low data rate (1-2 Kbps) with the data sent using the 
same downlinks as the sensor data. If the composite sensor 
data rate is low, SMALLSAT recognizes that it can be 
accommodated by the TT&C subsystem. If the composite data 
rate is high, SMALLSAT recognizes that another channel is 
required in the data handling subsystem. User input data relating 
to frequency band is used in conjunction with a look-up table to 
establish estimates of subsystem mass and power. 

Finally, SMALLSAT calculates the mass of the satellite structure 
as a percentage of the satellite wet mass. The structure mass is 
also influenced by payload dynamics and operating power level. 

Since the determination of the mass of a spacecraft subsystem 
depends upon the mass of each of the other subsystems (for 
example, ARC mass will depend upon sensor requirements as 
well as the mass of all other subsystems), SMALLSAT employs 
an iterative approach for establishing subsystem masses. In 
other words, as each subsystem is designed, all known masses 
are taken into account. Upon completion of the design of all 
subsystems, an iteration process may be initiated whereby the 
mass of each subsystem is recalculated taking into account 
updated knowledge of the masses of all other subsystems. This 
cycle is repeated until the mass computations converge. 

Cost Estimating Relationships._The cost estimating 
relationships utilized in the SMALLSAT Model are based upon 
those developed by the Aerospace Corporation. 2 

The basic concept underlying the development of cost estimating 
relationships is that cost is a function of one or more physical 
attributes of the item being costed and that this relationship is 
similar to or the same as that of other similar items. For 
example, the cost of a new satellite's attitude control subsystem 
is related to its mass in the same way that previously developed 
spacecraft attitude control subsystem costs are related to their 
mass. The development of CERs requires the development of a 
database of comparable costs for a number (hopefully large) of 
previously developed satellites and associated subsystems. A 
regression analysis is performed on the data to identify 
explanatory variables and to then develop a functional 
relationship between these variables and non-recurring and unit 
recurring cost. 


Subsystem-level small satellite CERs provided to Princeton Synergetics. 
Inc by the Aerospace Corporation on February 7, 1995. 
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Care must be taken with the use of the CERs since they are 
based upon historical data which may not be appropriate for use 
in estimating the cost of subsystems utilizing new technology. 
For example, the CERs predict that mass reduction will lead to 
cost reduction; this may not always be the case. In order to 
allow for this possibility, the CER derived cost results may be 
overridden and estimates provided (at the subsystem level) of its 
expected cost and its associated standard deviation. 

Valid ranges of all variables (as developed by the Aerospace 
Corp. based upon their database) are indicated for each of the 
developed CERs. Because the developed CERs are based 
upon the lower end of the small satellite range (as considered by 
SMALLSAT), there is a distinct possibility that SMALLSAT will 
calculate values for one or more variables that are outside of the 
valid ranges considered by the CERs When this occurs, 
SMALLSAT calculates the cost according to the CERs but 
indicates to the user that a potential problem may exist by 
changing the color of the cell containing the computed cost from 
green (indicating that no problem exists) to red. 

The results of the CERs are a set of estimates of non-recurring 
and recurring costs, by subsystem. Revisions may be made to 
these expected value estimates and standard deviations may be 
added. The total expected S/C bus non-recurring and recurring 
costs are the sums of the subsystem costs. Payload and 
payload integration costs are added to arrive at total expected 
satellite costs and standard deviations that may then be used in 
the life cycle cost analysis. 

The CERs are mostly based on the mass of subsystems. As 
subsystems associated with smaller and smaller spacecraft are 
created. The CERs quickly become invalid. The Aerospace 
Corporation is currently developing CERs based of subsystem 
performance and not its mass. 

Life Cycle Cost Analysis. A life cycle cost and availability 
model, SATCAV, is seamlessly linked to the Excel spreadsheet 
design model. This provides the user with the ability to observe 
the likely consequences of design choices and technology 
assumptions on mission life cycle costs and sensor availability 
statistics. SATCAV 3 is a dynamic stochastic life cycle cost and 
availability model that simulates the launch and on-orbit 
operations associated with the initiation and continuing operation 
of a generalized space mission comprising multiple satellites with 
multiple sensors. 

SPASIM: The Spacecraft Resource Simulator. The primary 
function of the SPAcecraft SIMulation (SPASIM) software is to 
simulate over time the utilization of resources during the 
operation of a spacecraft. SPASIM presents this virtual 
environment to the user in a graphical, object-oriented 
interface geared to enhance usability and integration. 

SPASIM can be used to validate spacecraft design and sizing 
estimates by performing an integrated time simulation of the 
spacecraft systems using three primary resources: power, 
data and propellant. This simulation can be used to identify 
resource bottlenecks or inadequacies resulting from 
assumptions made in the operational scenario of the 
spacecraft. Since SPASIM is a time-based simulation, 


SATCAV, developed by Princeton Synergetics, Inc., is a proprietary 
software product of PSi For inclusion in SMALLSAT, SATCAV has been 
modified so as to eliminate a number of unnecessary operational modes 
(such as on-orbit servicing and repair at a transportation node) Basically 
all other features remain intact. 


discrete events and duty cycles can be modeled and assessed 
across all spacecraft systems. Failure modes and operational 
contingencies can be evaluated allowing the analyst to 
optimize the spacecraft performance for a range of mission 
scenarios. The SPASIM interface allows the analyst to easily 
change system functional architectures via block diagrams and 
to easily update performance characteristics of system 
components with parameter input menus. SPASIM defines a 
set of system functional/architecture block diagrams wired 
together along with parameters that describe operational and 
performance characteristics that yields a well documented 
functional spacecraft model. 

Each block within a GUI window defines a function through a 
hierarchy of lower level blocks. Blocks at the lowest level 
invoke MATLAB® code or externally-defined functions. The 
GUI presents a dialog box to the user that allows changes to 
be made to a block's parameters before simulation starts. By 
changing appropriate parameters in a model, the user can 
assess the impacts of using different technologies. Lines 
connecting the blocks represent the flow of resources such as 
power, data, and thermal energy and propellant. 

The user can analyze subsystem interactions during a 
simulation by displaying real-time plots of any block's input or 
output values. A large selection of predefined plots are 
included in the simulator. Using the scope block in Simulink, 
additional graphs may be displayed in order to gain further 
insight into the subsystems. 

SPASIM includes a small library of models of spacecraft 
subsystems and components. SPASIM's system resource 
simulation has six subsystem models: Power, Thermal, 
Propulsion, Guidance Navigation and Control (GN&C), 
Communication and Tracking (C&T), and Command and Data 
Handling (C&DH). Payload instruments are modeled based on 
their resource usage requirements and duty cycles. They 
communicate resource requests to the spacecraft through a 
standard interface. 

Usage Requirements SPASIM is composed of two types of 
programs: user interface programs and external routines. The 
user interface programs are MATLAB® scripts that include 
MATLAB® commands and SIMULINK® files. Both the internal 
MATLAB® code and the MATLAB® scripting language are 
hardware independent, available on various platforms such as 
SGI, PC, Mac, and Sun. The external routines are written in 
ANSI standard C and must be compiled each time SPASIM is 
moved to a different platform. 

Technical Description SPASIM is a collection of MATLAB 
User Interface Programs and External Routines (ANSI C 
procedures compiled into MATLAB EXecutible "MEX" files) 
that run under the standard MATLAB environment. The 
SIMULINK Tool box is required to run SPASIM. 

There are seven systems described in the following 
subsections. Each section describes the default input values 
and the architecture of the schematic design for a system. 

1 . Payload 

2. Power System 

3. Thermal System 

4. Propulsion System 

5. Guidance Navigation and Control System 

6. Communications and Tracking System 

7. Command and Data Handling System 
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The system schematic for the spacecraft bus can be seen in 
Figure 2. 

The Payload Block serves as an interface between the 
payloads and the Bus. The default spacecraft modeled in 
SPASIM is a spacecraft in development by the US 
Government. There are four payloads on this spacecraft 
represented by the block diagram in Figure 3. Spacecraft 
Bus requirements from the Bus flow in from the left. The 
resource requirements are filtered through the four payloads 
which add and subtract from the flow. Finally the resource 
stream is concatenated and fed back to the spacecraft bus as 
payload resource requirements. 

Payload Description. Each of the four instruments in the 
block share a common type of interface with the spacecraft 
The block diagram a typical payload is shown Figure 4. This 
is a typical functional schematic for a spacecraft resource 
model of an instrument. The spacecraft bus requirements flow 
in from the left into a demultiplexer and resources are 
deconvolved to be available for the instrument to use. The 
altimeter has a nominal power rating of 75.5 watts. This is 
modeled as a constant block which feeds into the power port 
on the resource multiplexer. Also, the nominal data stream is 
modeled as 152 bit word plus a Vehicle Time Code Word 
divided by the number of samples per second to yield a bit per 
second rate for the Altimeter. A second mode of operation is 
modeled directly below, but it is not implemented. Thus an 
alternate data generation is available to be connected to 
simulate a major calibration period. The power and data 
resource streams are modeled and feed into the Combination 
Multiplexer, which in turn feeds these resource requirements 
back to the spacecraft bus. 

Power Subsystem. The power subsystem is a graphical 
model of a generic power system. Power is a managed 
resource within this model, and it includes the following 
components: 

Solar Array 
Charge Unit 
Battery 

Spacecraft Power Requirements 
Internal Power Consumption 
Logic to Evaluate Power Levels 
Other Power Subsystem Requirements 

Error! Reference source not found, is a top-level schematic 
of the power subsystem hierarchy, containing each of the 
above components. The following sections describe the 
contents and functions of these components, as well as the 
interactions between them. 

The Power System is initialized by values from a default file 
which the user can modify through the power parameters 
menu or by editing the defaults file directly. 

These variables are set at the beginning of the simulation. The 
values of the variables are constant during the simulation. 
Calculated values are dependent on the model of the system. 

Solar Arrays. The schematic of the solar array, Figure 6, 
includes five functional components: 

• Orbital Information 

• Default Parameters 


• Solar Array Pointing Program 

• Solar Array Shadow Table 

• Other Default Values 

The Orbit Parameters enter via an input port on the left. The 
instantaneous orbital radius, true anomaly, and eccentricity are 
combined with default initial parameters for the solar array and 
are passed to the Array Pointing Algorithm in the "Array 
Power" function block. This algorithm uses default initial 
parameters (Argument of Perigee, Right Ascension, 

Inclination, Start Date, Epoch Date, and Inertial Attitude) along 
with time-varying parameters to point the solar array normal 
vector as close as possible toward the sun. The algorithm uses 
the current position and attitude of the spacecraft to point the 
array, subject to the number of degrees of freedom that the 
user has specified in the Power Defaults Menu. The output of 
the function is a three component vector that includes: the 
cosine of the angle between the solar array normal and the 
spacecraft-sun direction, and the alpha and beta angles from 
the spacecraft to the sun (Kumar and Heck). The alpha and 
beta angles are used as inputs for the Shadow Table. The 
Shadow Table is an ASCII file, loaded before the start of the 
simulation, and used by a two-dimensional look-up function in 
SIMULINK. This look-up function linearly interpolates the 
fraction (0.0 to 1 .0) of the solar array area available at specific 
alpha and beta angles for the spacecraft in a nominal LVLH 
flight attitude. The maximum current power is calculated from 
the following: array area, solar cell efficiency, user-entered 
Solar Flux (default is yearly average flux: 1327 W/m 2 ), solar 
cell degradation, radiation, atomic oxygen, etc., and an initial 
on-orbit power factor. 

The calculated array pointing values and the results of the 
shadow table lookup are combined with the value of the 
maximum current power calculation, which results in total 
instantaneous power of the solar array. This value is the 
output of the Solar Array block. 

9. Other Power Systems Requirements of Bus 

The Power system manages the Power for the spacecraft. The 
Power System is currently adding to the power resource 
stream and the data resource stream. The previous stream is 
discussed above. The latter is a single constant place holder 
for data that could be generated by the charging unit as an 
example. 

In all, each of the subsystems has been implemented in the 
simulation. Output is that of time-based simulations of the 
resource (data, power and/or propellant) as it is either created 
or utilized during the mission. 

System Outputs. SPASIM’s outputs are those of a series of 
time-histories of spacecraft events. A sample of these events 
are: Thruster firings, propellant usage, battery depth of 
discharge, communication slant range, data buffer usage, 
attitude euler angles and orbital ground track. There are over 
30 standard outputs that can be menu-selected. In addition, 
one can place “scopes”, pre-formatted output plots, at any 
output port in any subsystem thus allowing flexibility in the 
simulator for the user to exploit. 

An Example Case 

The spacecraft and sensors branch at NASA Langley 
performed a phase A study of an electronically scanning 
thinned-array radiometer (ESTAR) 
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Table 1 shows the following inputs provided by ESTAR for 
SMALLSAT. 

The results of these inputs are compared with the results of the 
Phase A study in Table 2. 

Although the mass and power values are within 15% of the 
Phase A Estimate, a further investigation of the subsystem 
mass and power values show that there are fluctuations of 
greater than 30%, This can be explained due to the design 
methods of the group. By this, SMALLSAT is NOT meant to 
be an all-in-all program that produces a spacecraft point design 
given mission and subsystem requirements. Both the 
simulator and the design and sizing routines presented here a 
but a tool to reduce the time and effort spent in this particular 
design phase. Ingenuity can not be captured in algorithms 
nor should it be. The innovativeness of the designers and the 
design team is what is necessary for a feasible and attractive 
design. 

Summary 

The primary function of the SSDSE is to assist in designing, 
sizing and simulating satellite systems based on mission and 
payload requirements and current/advanced satellite systems 
data. There are three core SSDSE modules. 

The System Design and Sizing Module is where the concept 
definition begins. Given a set of mission/payload requirements 
and constraints the System Design and Sizing Module 
synthesizes subsystem characteristics. 


The System Resource Simulation Module utilizes the newly 
generated subsystem characteristics parameters to perform an 
integrated timed simulation of the spacecraft systems to 
identify resource bottlenecks or inadequacies resulting from 
simple assumptions in the System Design and Sizing Module. 
Adjustments are then made in the subsystem characteristics to 
eliminate the problems identified in the simulation. 

The Component Level Database is then used to identify actual 
candidate system components based on the subsystem 
characteristics definition or to flag technology tall polls if 
components with the required characteristics do not exist. The 
Component Level Database could also be used as a starting 
template for the design process based on historical 
mission/system data. 

Once a detailed satellite description has been generated, the 
Costing Module is utilized to assess whether the concept 
design falls within funding allocations. Adjustments in mission 
requirements and technology assumptions can then be 
changed and the cycle repeated. 

Given an actual Phase A analysis, the design and sizing 
module can estimate spacecraft mass and power to within 
15%. As with any tool, this is not an expert system. The 
designers are the experts. The tool is merely an instrument to 
perform the interdisciplinary analyses in an organized and 
timely fashion. Innovation and Ingenuity are left to the 
designer. 
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Table 1. ESTAR Mission Parameters Input into SMALLSAT 


SMALLSAT Inputs provided by ESTAR 

Operational Altitude 

402 km 

Inclination 

sunsynch. (97.03 deg) 

Launch Vehicle 

Taurus 

Pointing Accuracy 

0.3 deg 

Launch Year 

1998 

Mission Lifetime 

3 years 

Payload 

L-Band Radiometer 

Pointing Knowledge 

0.02 deg, continuous 

Momentum Device 

Momentum Wheel 

Solar Cell 

GaAs 

Payload Data Rate 

2.5 GBit/orbit 


Table 2. Comparison between SMALLSAT and Phase A Study 



SMALLSAT 
Mass, kg 

Default SMALLSAT 
Mass, Power, W 

kg 

Default 

Power, 

W 

S Experiment 

178.0 

178.43 | 249 

248.21 

| Spacecraft 

Data 

Management 

Orbit 

Determination 

Structure 

Ordinance 

Thermal 

Communications 
Propulsion 
Electrical Power 
Attitude Control 
Expendables 

31.2 

33.76 

93 

106.59 

11.2 

2.41 

27.76 

4.18 

55 

51.87 

0.00 

0.00 

0.00 

9.29 

0.00 

0.00 

15 

6.01 

31.57 

16.5 

16.2 

13.65 

38.0 

39.88 

9 

17.43 

4 

3.99 

162 

99.67 

30.6 

28.70 

21.83 

20.20 

52.0 

25.15 

98.3 

102.45 


0.00 

Totals 

597.73 

535.17 

525.93 

473.20 
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Figure 1. SSDSE General Structure 


Spacecraft Systems 



Figure 2. SPASIM Spacecraft Block Diagram 
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Figure 3. Payload Subsystem Default Block Diagram 



Figure 4. Payload Resource Usage Diagram 








Figure 6. SPASIM Default Solar Array Model 
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